"playground" is part of the workspace, so I need to be listed here for rewatch to pick up the correct node_modules folder.

The package.json has rescript clean in the commands.
This will now accurately only clean the playground package.

But it needs that link to the parent rescript json.

-v is verbosity and this was trying to compile the testrepo with an older installed version of rescript.
I'm not sure how this wasn't leading to bigger problems.

This streamlines the many workspace: Option<string> checks that were being done.

It improves the readability and debugability of rewatch.

I would maybe do:

pub enum MonoRepoContext {
  Root {local_dependencies, local_dev_dependencies}
  Package {parent_config: Config, parent_path: RescriptJsonPath}
}

pub struct ProjectContext {
  config: Config,
  path: RescriptJsonPath,
  mono_repo_context: Option<MonoRepoContext>
}

I would like to be mindful about memory consumption - even if minor - you never know how much these will grow in the future - and I think we should try and keep a small footprint (smaller than we do now). I think the enum will otherwise always take the biggest size when allocating, even in smaller contexts.

More of a note to myself for some future refactor - I think we can do better with memory management - the package specs / root_config and those things are essentially constant after reading. We should be able - for the most part - to just always return references rather than cloning - I think we can further smallen the footprint / make things quite a bit faster that way

This function also get's called a lot. I think we might benefit from some more abstraction, having an internal representation for a package / packagespec, rather than the parseTree we need for Serde

5 usages indeed, worth revisiting. Will consider this outside the scope of this PR, as it is already so large.

we pass references right? Where are we doing cloning?

I would maybe do:

pub enum MonoRepoContext {
  Root {local_dependencies, local_dev_dependencies}
  Package {parent_config: Config, parent_path: RescriptJsonPath}
}

pub struct ProjectContext {
  config: Config,
  path: RescriptJsonPath,
  mono_repo_context: Option<MonoRepoContext>
}

I would like to be mindful about memory consumption - even if minor - you never know how much these will grow in the future - and I think we should try and keep a small footprint (smaller than we do now). I think the enum will otherwise always take the biggest size when allocating, even in smaller contexts.

format + iter + join can be done more efficiently with write! without any additional intermediate overhead;

let mut output = String::from("[\n{");
for dep of dependencies {
  fmt::write(&mut output, format!("  \"{dep}\,\n"")).expect("Error");
}
fmt::write(&mut output, "}\n]").expect("Error");

output

If you really want to fly - I think multiple write operations in the loop would be even faster than serializing the dep with formatter, as it's already a string - but I'm not quite sure how much faster it would be.

Ah - I see it's used within fmt only - perhaps push it into that context, then we'll know it's not used for anything outside of formatting / performance matters less

I would try to maybe remove the nesting ever so slightly here - nesting multiple matches. Perhaps break out the config reading to another function as well?

Breaking up the enum into a struct for the shared fields would remove the need for these too, which is nice imo :)

It's not exactly the same, because we want to get different things (in a mono repo package, get the root config, otherwise get the config of the current package). So I think it's pretty nice like this - and with an implementation, it's easy to get the configuration.

I think maybe there is an extend function or something like that.
I'm not sure what the underlying representation of the hashset is, but a bulk operation will be more optimized. So probably something like:

let deps = local_dev_dependencies.into_iter().collect::AHashSet<String>();
local_packages.extend(deps)

Is faster because the CPU can plan ahead better.

Super nice, I like this a lot!